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1.0  Introduction  /  ,  z 

— ^  To  validate  my  thesis  (DeLoach,  1987),  that  environnients  based  on  abstract  interfaces  provide 
enhanced  portability  and  extensibility,  I  decided  to  compare  my  environment  against  existing  non-interface 
based  environments.  To  do  this,  1  needed  two  metrics:  one  to  measure  portability,  and  the  other  to  meas¬ 
ure  extensibility.  These  metrics  had  to  be  applicable  to  the  environment  as  a  whole  and  had  to  exhibit  the 
following  characteristics.  First,  the  metrics  had  to  be  objective:  given  sufficient  knowledge  of  the  system, 
an  individual  should  be  able  to  compute  only  one  possible  measurement.  Second,  the  metric  must  be  appli¬ 
cable  given  only  the  environment  design  documentation  and  source  code,  thus  ensuring  the  metrics  are 
based  solely  on  the  characteristics  of  the  software. 


2.0  Portability  Measurement 

Intuitively,  software  (environment)  portability,  "the  ease  of  movement  among  distinct  solution 
environments"  and  "a  function  of  the  number  and  complexity  of  the  requisite  changes"  (Yourdon  and  Con¬ 
stantine,  1978:  322),  should  be  fairly  easy  to  measure.  There  have  been  two  approaches  to  measuring 
software  portability.  The  first  approach  describes  portability  in  terms  of  the  effort  expended  to  rehost  the 
software.  Although  this  approach  measures  both  size  and  complexity,  it  also  includes  other  factors  such  as 
personal  skills,  tool  availability,  etc. 

The  second  approach  is  simple  and  straightforward.  It  measures  the  amount  of  code  changed  during 
the  rehosting  process.  Although  it  dees  measure  the  change  size  and  is  dependent  solely  upon  the  software, 
it  does  not  measure  the  complexity.  However,  an  extension  to  the  lines  of  code  approach  that  considered 
complexity  could  meet  the  metric  requirements  discus-sed  above. 

Change  complexity  includes  many  components,  most  of  which  are  hard  to  measure  (e.g.  understand¬ 
ing  new  host  operating  systems,  simulating  non-existent  host  computer  functions,  intrinsic  difficulty  of  the 
function,  etc  ).  However,  one  important  aspect  of  complexity  that  is  quantifiable  is  localization  of  the 
changes.  If  a  piece  of  software  requires  changes  to  500  lines  of  code,  it  is  much  easier  to  rehost  if  the 
changes  are  located  in  five  modules  instead  50-  Therefore,  1  propose  to  measure  the  size  of  the  change  by 
lines  of  code  and  the  complexity  by  locality  of  the  changes  (how  many  modules  or  packages  have  to  be 
changed).  Therefore,  the  size  of  a  change  is  simply: 

size  =  (1  - 

where  is  the  number  of  source  lines  of  code  added,  deleted,  or  modified,  and  is  the  total  number  of 
source  lines.  (Source  lines  are  defined  as  one  executable  or  declarative  statement.) 

The  locality  (complexity)  of  the  portability  changes  is  described  in  two  parts:  modularity  and  local¬ 
ity.  Modularity  describes  the  percentage  of  modules  changed  whereas  locality  describes  the  number  of 
packages  changed.  Modularity  is  computed  as: 

modularity  =  (l  - 

where  N  ^  is  the  number  of  modules  requiring  change  and  is  the  number  of  total  modules.  Likewise, 
the  legality  of  changes  is  computed  as: 


locality  =  (1  - 


where  N  is  the  number  of  packages  changed  and  is  the  total  number  of  packages  in  the  system. 

The  overall  environment  portability  is  then  computed  as  the  average  of  the  individual  portabilit\ 
metrics. 
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portability  =  (size  +  modularity  +  locality)  3 


When  talking  about  the  portability  of  a  single  component,  it  is  usually  rather  difficult  to  talk  about 
locality  as  defined  above  since  each  component  probably  consists  of  ver>'  few  and  probably  only  one  pack¬ 
age.  Therefore,  to  measure  the  portability  of  a  single  environment  component,  only  the  sire  and  modular¬ 
ity  are  used. 


component  portability  =  (site  modularity)  /  2 


3.0  Extensibility  Measurement 

Environment  extensibility  has  been  defined  as  the  ab^ility  of  an  environment  to  adapt  to  major 
changes  in  the  environment’s  capabilities  and  has  four  basic  components 

Tool  Modification 
New  Tool  Integration 
Existing  Tool  Integration 
Database  Extension 

Although  extensibility  has  been  recognized  as  being  a  critical  factor  in  environment  success,  there  has 
been  no  real  attempt  to  measure  it.  In  the  more  general  case,  extensibility  is  usually  considered  part  of 
software  maintenance.  It  is  also  generally  accepted  that  software  structure  (modularity)  is  critical  to 
software  maintainability  (Glass,  1979:  158). 

The  quality  of  program  modularity  is  measured  by  two  well  accepted  measures:  coupling  and  cohesion 
(Pressman,  1982;  158).  Because  environment  extensibility  is  similar  to  normal  software  system  extensibil¬ 
ity  (think  of  each  environment  component  as  a  module),  a  measure  similar  to  coupling  and  cohesion  is  pro¬ 
posed  to  determine  environment  extensibility.  Therefore,  I  have  developed  four  levels  of  extensibility  to 
measure  two  basic  areas:  tool  integration  and  database  extension.  To  measure  the  quality  of  environment 
extensibility,  each  type  of  extensibility  (tool  integration  or  database  extension)  is  placed  into  one  or  more 
of  the  following  categories. 

Indirectly  Extensible 
Directly  Extensible 
Tcx)l  Extensible 
Structure  Extensible 

Indirect  Extensibility  refers  to  the  ability  to  integrate  a  tool  or  data  object  through  use  of  data  struc¬ 
tures  external  to  the  environment  components.  An  analogy  to  this  type  of  extensibility  is  indirect  address¬ 
ing  In  indirect  addressing,  the  program  code  refers  to  a  known  location  that  bolds  the  desired  address 
This  type  of  extensibility  is  powerful  because  it  allows  simple  integration  yet  remains  very  flexible. 

Direct  Extensibility  is  similar  to  indirect  extensibility  in  that  it  requires  no  change  to  the  environment 
components  themselves.  In  the  case  of  direct  extensibility,  instead  of  changing  an  external  data  structure, 
the  new  tcx)l  or  object  is  required  to  meet  the  environment’s  non-modifiable  reference  scheme  (i.e  a  tool 
mu.'it  be  placed  in  a  particular  directory).  Although  direct  extensibility  may  require  less  effort  than  indirect 
extensibility,  it  is  also  less  flexible.  Again,  the  analogy  for  direct  extensibility  can  be  made  to  direct 
addressing  where  the  actual  address  is  placed  directly  in  the  program  code  If  the  address  changes,  the  pro¬ 
gram  must  be  modified  everywhere  the  address  is  used. 

Tool  Extensibility  refers  to  a  situation  where  to  integrate  a  tool  or  database  object,  one  or  more  tools 
must  be  altered  A  common  example  of  this  is  when  a  environment’s  command  line  interpreter  must  be 
changed  to  recognize  a  new  tool,  or,  when  the  database  tool  must  be  changed  to  allow  incorporation  of  new 
object  types  This  type  of  change,  as  a  minimum,  requires  recompilation  and  retesting  of  all  the  environ¬ 
ment  components  affected. 

The  worst  type  of  extensibility  b  structure  extensibility.  In  structure  extensibility,  the  overall  struc¬ 
ture  of  the  environment  must  be  changed  to  incorporate  new  tools  or  database  objects  If  the  structure  of 


the  environment  changes,  then  the  assumptions  made  about  the  environment  change  causing  an  enormous 
amov  it  redesign,  retest,  and  reintegration  of  environment  components.  Obviously,  this  type  of  extensi- 
bilit  ^hly  undesirable. 

ompute  a  single  environment  extensibility  rating  requires  associating  values  with  each  type  of 
exteu  iiaty  discussed  abov^.  To  develop  a  quality  metric,  a  considerable  effort  would  be  required  to  deter¬ 
mine  how  much  better  or  worse  any  one  particular  type  of  environment  extensibility  is  than  the  others. 
However,  because  exact  numbers  are  not  necessary  to  show  a  general  trend,  intuitive  estimate  for  these 
values  are  used.  The  following  equations  reflect  that  estimate 

tool  extensibility  =  PN.  +  5*N  +  20*N  -t-  100*N 

I  d  I  I 

database  extensibility  =  1*N  +  5*N  4-  20*N  100*N 

■  d  t  ■ 

extensibility  —  tool  extensibility  -  database  extensibilitj 

where  N  is  the  number  of  indirect  references  modified,  is  the  number  of  direct  references  satisfied,  N  is 
the  number  of  tools  modified,  and  N  is  the  number  of  structural  modifications.  Therefore,  to  apply  t\iis 
measure,  each  category  of  extensibility  (and  the  number  of  times  it  applies)  is  counted,  multiplied  by  its 
associated  weight,  and  then  summed. 
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